This PR adds the electra beacon chain configuration for mainnet.

This PR fixes a deadlock situation is deleteTailEpoch that might arise
when
range delete is running in iterator based fallback mode (either using
leveldb
database or the hashdb state storage scheme). 

In this case a stopCb callback is called periodically that does check
events,
including matcher sync requests, in which case it tries to acquire
indexLock
for read access, while deleteTailEpoch already held it for write access.

This pull request removes the indexLock acquiring in
`FilterMapsMatcherBackend.synced`
as this function is only called in the indexLoop.

Fixes ethereum#31700

TruncatePending shows up bright red on our nodes, because it computes
the length of a map multiple times.
I don't know why this is so expensive, but around 20% of our time is
spent on this, which is super weird.

```
//PR: BenchmarkTruncatePending-24    	   17498	     69397 ns/op	   32872 B/op	       3 allocs/op
//Master: BenchmarkTruncatePending-24    	    9960	    123954 ns/op	   32872 B/op	       3 allocs/op
```

```
benchmark                       old ns/op     new ns/op     delta
BenchmarkTruncatePending-24     123954        69397         -44.01%

benchmark                       old allocs     new allocs     delta
BenchmarkTruncatePending-24     3              3              +0.00%

benchmark                       old bytes     new bytes     delta
BenchmarkTruncatePending-24     32872         32872         +0.00%
```
This simple PR is a 44% improvement over the old state


``` 
OUTINE ======================== github.com/ethereum/go-ethereum/core/txpool/legacypool.(*LegacyPool).truncatePending in github.com/ethereum/go-ethereum/core/txpool/legacypool/legacypool.go
     1.96s     18.02s (flat, cum) 19.57% of Total
         .          .   1495:func (pool *LegacyPool) truncatePending() {
         .          .   1496:	pending := uint64(0)
      60ms      2.99s   1497:	for _, list := range pool.pending {
     250ms      5.48s   1498:		pending += uint64(list.Len())
         .          .   1499:	}
         .          .   1500:	if pending <= pool.config.GlobalSlots {
         .          .   1501:		return
         .          .   1502:	}
         .          .   1503:
         .          .   1504:	pendingBeforeCap := pending
         .          .   1505:	// Assemble a spam order to penalize large transactors first
         .      510ms   1506:	spammers := prque.New[int64, common.Address](nil)
     140ms      2.50s   1507:	for addr, list := range pool.pending {
         .          .   1508:		// Only evict transactions from high rollers
      50ms      5.08s   1509:		if uint64(list.Len()) > pool.config.AccountSlots {
         .          .   1510:			spammers.Push(addr, int64(list.Len()))
         .          .   1511:		}
         .          .   1512:	}
         .          .   1513:	// Gradually drop transactions from offenders
         .          .   1514:	offenders := []common.Address{}
```

```go
// Benchmarks the speed of batch transaction insertion in case of multiple accounts.
func BenchmarkTruncatePending(b *testing.B) {
	// Generate a batch of transactions to enqueue into the pool
	pool, _ := setupPool()
	defer pool.Close()
	b.ReportAllocs()
	batches := make(types.Transactions, 4096+1024+1)
	for i := range len(batches) {
		key, _ := crypto.GenerateKey()
		account := crypto.PubkeyToAddress(key.PublicKey)
		pool.currentState.AddBalance(account, uint256.NewInt(1000000), tracing.BalanceChangeUnspecified)
		tx := transaction(uint64(0), 100000, key)
		batches[i] = tx
	}
	for _, tx := range batches {
		pool.addRemotesSync([]*types.Transaction{tx})
	}
	b.ResetTimer()
	// benchmark truncating the pending
	for range b.N {
		pool.truncatePending()
	}
}
```

This PR adds checking for an edgecase which theoretically can happen in
the range-prover. Right now, we check that a key does not overwrite a
previous one by checking that the key is increasing. However, if keys
are of different lengths, it is possible to create a key which is
increasing _and_ overwrites the previous key. Example: `0xaabbcc`
followed by `0xaabbccdd`.

This can not happen in go-ethereum, which always uses fixed-size paths
for accounts and storage slot paths in the trie, but it might happen if
the range prover is used without guaranteed fixed-size keys.

This PR also adds some testcases for the errors that are expected.

This PR applies the config overrides to the new config as well,
otherwise they will not be applied to defined configs, making
shadowforks impossible.

To test:
```
>  ./build/bin/geth --override.prague 123 --dev --datadir /tmp/geth
INFO [04-28|21:20:47.009]  - Prague:                      @123
> ./build/bin/geth --override.prague 321 --dev --datadir /tmp/geth
INFO [04-28|21:23:59.760]  - Prague:                      @321
``

For PeerDAS, we need to compute cell proofs. Both ckzg and gokzg support
computing these cell proofs.
This PR does the following:

- Update the go-kzg library from "github.com/crate-crypto/go-kzg-4844"
to "github.com/crate-crypto/go-eth-kzg" which will be the new upstream
for go-kzg moving forward
- Update ckzg from v1.0.0 to v2.0.1 and switch to /v2
- Updates the trusted setup to contain the g1 points both in lagrange
and monomial form
- Expose `ComputeCells` to compute the cell proofs